RSA encryption padding change from PKCS1Padding to OAEPWithSHA-256And… #834

utkrishtsahu · 2025-05-19T05:13:19Z

RSA encryption padding change from PKCS1Padding to OAEPWithSHA-256And

Changes

Updated padding for RSA encryption from PKCS1Padding to OAEPWithSHA-256And also checked for migration for the same.

References

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. Since this library has unit testing, tests should be added for new functionality and existing tests should complete without errors.

[X ] This change adds unit test coverage
[X ] This change adds integration test coverage
[ X] This change has been tested on the latest version of the platform/language or why not

Checklist

I have read the Auth0 general contribution guidelines
I have read the Auth0 Code of Conduct
All existing and new tests complete without errors

semgrepcode-auth0 · 2025-05-19T05:14:28Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+                                "("+ OLD_PKCS1_RSA_TRANSFORMATION +") for migration due to " +
+                                "InvalidKeyException with OAEP.");
+                        KeyStore.PrivateKeyEntry rsaKeyEntry = getRSAKeyEntry();
+                        Cipher rsaPkcs1Cipher = Cipher.getInstance(OLD_PKCS1_RSA_TRANSFORMATION);


Semgrep identified an issue in your code:
Weak cryptographic algorithm detected. The DES, 3DES, RC2, RC4, MD4, MD5, SHA1, BLOWFISH, Dual_EC_DRBG, and SHA1PRNG algorithms are considered insecure and should not be used. Using weak cryptographic algorithms can compromise the confidentiality and integrity of sensitive data. It is recommended to adopt only cryptographic features and algorithms offered by the Android platform that are internationally recognized as strong. It is also fundamental to ensure that the encryption parameters (crypto key, IV, etc.) are generated randomly using a cryptographically strong PRNG function. In addition, if it is needed to store an encryption parameter on the device, a secure storage mechanism like the Android KeyStore must be used.

To resolve this comment:

🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by android_weak_cryptographic_algorithm.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

The primary digest used for the RSA-OAEP padding scheme is SHA-256, which is secure.

SHA1 is included only as a supported digest for the Mask Generation Function (MGF1), an internal component of OAEP.

This is a standard practice to ensure maximum compatibility across different Android OS versions and hardware security modules, as some implementations require SHA1 to be available for MGF1.

semgrepcode-auth0 · 2025-05-19T05:14:29Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+                        Log.d(TAG, "Attempting to decrypt AES key with PKCS1Padding ("+
+                                OLD_PKCS1_RSA_TRANSFORMATION +") for migration.");
+                        KeyStore.PrivateKeyEntry rsaKeyEntry = getRSAKeyEntry();
+                        Cipher rsaPkcs1Cipher = Cipher.getInstance(OLD_PKCS1_RSA_TRANSFORMATION);


Weak cryptographic algorithm detected. The DES, 3DES, RC2, RC4, MD4, MD5, SHA1, BLOWFISH, Dual_EC_DRBG, and SHA1PRNG algorithms are considered insecure and should not be used. Using weak cryptographic algorithms can compromise the confidentiality and integrity of sensitive data. It is recommended to adopt only cryptographic features and algorithms offered by the Android platform that are internationally recognized as strong. It is also fundamental to ensure that the encryption parameters (crypto key, IV, etc.) are generated randomly using a cryptographically strong PRNG function. In addition, if it is needed to store an encryption parameter on the device, a secure storage mechanism like the Android KeyStore must be used.

🧼 Fixed in commit 715bcc8 🧼

The primary digest used for the RSA-OAEP padding scheme is SHA-256, which is secure.

SHA1 is included only as a supported digest for the Mask Generation Function (MGF1), an internal component of OAEP.

This is a standard practice to ensure maximum compatibility across different Android OS versions and hardware security modules, as some implementations require SHA1 to be available for MGF1.

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

Copilot

Pull Request Overview

This PR updates the RSA encryption padding from PKCS1Padding to OAEPWithSHA-256AndMGF1Padding for improved security. The change includes backward compatibility handling to migrate existing PKCS1-encrypted AES keys to the new OAEP format.

Changes RSA transformation from PKCS1Padding to OAEPWithSHA-256AndMGF1Padding
Increases RSA key size from 2048 to 4096 bits
Implements migration logic for existing PKCS1-encrypted AES keys to maintain compatibility

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
CryptoUtil.java	Updates RSA transformation, key size, and implements migration logic for PKCS1 to OAEP transition
CryptoUtilTest.java	Refactors tests to support new RSA transformation and adds migration test coverage

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

Copilot · 2025-08-19T06:55:53Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+                storage.store(KEY_ALIAS, newEncodedEncryptedAES);
+                storage.remove(OLD_KEY_ALIAS);
+                return decryptedAESKey;
+            } catch (Exception e) {


Catching generic Exception is too broad and may hide specific error conditions. Consider catching specific exceptions like BadPaddingException, IllegalBlockSizeException, NoSuchAlgorithmException, etc., to handle different failure scenarios appropriately.

Suggested change

} catch (Exception e) {

} catch (NoSuchAlgorithmException | NoSuchPaddingException | InvalidKeyException | BadPaddingException | IllegalBlockSizeException | KeyStoreException | UnrecoverableEntryException e) {

made new changes on 17 dec will check on copilot review on it.

Copilot · 2025-08-19T06:55:54Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

-            Log.e(TAG, "Error while creating the AES key.", e);
+            Log.e(TAG, "Error while creating the new AES key.", e);
            throw new IncompatibleDeviceException(e);
+        } catch (Exception e) {


Catching generic Exception is too broad. This catch block should handle specific exceptions that can occur during RSA encryption or storage operations, such as CryptoException or IncompatibleDeviceException.

Suggested change

} catch (Exception e) {

} catch (InvalidKeyException

| NoSuchPaddingException

| IllegalBlockSizeException

| BadPaddingException

| KeyStoreException

| UnrecoverableEntryException

| CertificateException

| IOException

| ProviderException e) {

made new changes on 17 dec will check on copilot review on it.

pmathew92 · 2025-08-19T06:58:55Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

    // https://developer.android.com/reference/javax/crypto/Cipher.html
    @SuppressWarnings("SpellCheckingInspection")
    private static final String AES_TRANSFORMATION = "AES/GCM/NOPADDING";
+    private static final String OLD_PKCS1_RSA_TRANSFORMATION = "RSA/ECB/PKCS1Padding";


Add a comment to state why OLD_PKCS1_RSA_TRANSFORMATION is being used

pmathew92 · 2025-08-19T07:03:02Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

                        .setKeySize(RSA_KEY_SIZE)
-                        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_RSA_PKCS1)
+                        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_RSA_OAEP)
+                        .setDigests(KeyProperties.DIGEST_SHA256, KeyProperties.DIGEST_SHA1)


Hope this setDigest addition was also reviewed by security ?

pmathew92 · 2025-08-19T09:04:06Z

@utkrishtsahu The current implementation doesn't handle migration for existing users token . Please handle that and ensure it doesn't break

…gration logic for existing user

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

utkrishtsahu · 2025-12-17T06:08:42Z

@claude

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

Comments suppressed due to low confidence (1)

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java:391

String concatenation using += in a loop can be inefficient. While this particular loop is expected to be short (traversing the exception chain), it's better practice to use a StringBuilder for string concatenation. This improves performance and is more maintainable if the loop grows longer in the future.

            throw new IncompatibleDeviceException(e);
        } catch (IllegalBlockSizeException | BadPaddingException e) {
            /*
             * They really should not be thrown at all since padding is requested in the transformation.
             * Delete the AES keys since those originated the input.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-12-19T09:03:36Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+        if (!TextUtils.isEmpty(encodedEncryptedAES)) {
+            byte[] encryptedAESBytes = Base64.decode(encodedEncryptedAES, Base64.DEFAULT);
+            try {
+                return RSADecrypt(encryptedAESBytes);


Missing validation of the decrypted AES key length after PKCS1 decryption. The original getAESKey implementation validated that the AES key has the expected length (32 bytes for 256-bit AES) before returning it. Without this validation, a corrupted or malformed legacy key could be migrated and cause issues later. Consider validating that decryptedAESKey.length equals AES_KEY_SIZE / 8 before proceeding with re-encryption.

Suggested change

return RSADecrypt(encryptedAESBytes);

byte[] decryptedAESKey = RSADecrypt(encryptedAESBytes);

// Validate that the decrypted AES key has the expected length (e.g. 32 bytes for 256-bit AES)

if (decryptedAESKey == null || decryptedAESKey.length != AES_KEY_SIZE / 8) {

// Treat this as corrupted key material: clean up and signal an error

deleteRSAKeys();

deleteAESKeys();

throw new CryptoException("The RSA decrypted AES key has an unexpected length.");

}

return decryptedAESKey;

The current code already throws exceptions on decryption failures. If additional validation is desired, it should be addressed in a separate PR to avoid scope creep and maintain backward compatibility

Copilot · 2025-12-19T09:03:37Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+                             NoSuchPaddingException | InvalidKeyException | 
+                             IllegalBlockSizeException | BadPaddingException ex) {
+                        Log.e(TAG, "Could not migrate. A new key will be generated.", ex);
+                        deleteRSAKeys();


Catching a generic Exception here is overly broad and could hide unexpected issues. The catch block swallows all exceptions (including potential runtime exceptions) and simply generates a new key, which could mask serious bugs. Consider catching only the specific checked exceptions that can be thrown by the operations inside the try block (NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, IllegalBlockSizeException, BadPaddingException, CryptoException, KeyStoreException, CertificateException, IOException, UnrecoverableEntryException) to maintain better error visibility.

This exception handling is in the OLD_KEY_ALIAS migration path (lines 464-467), which is unrelated to the PKCS1→OAEP security migration that this PR addresses. The generic Exception catch block existed in the original code and was not modified by this PR.

Copilot · 2025-12-19T09:03:37Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+                    rsaKeyEntry.getPrivateKey()
+                );
+
+                byte[] encryptedAESWithOAEP = RSAEncrypt(decryptedAESKey);


Catching a generic Exception here is overly broad and could mask programming errors or unexpected runtime exceptions. The outer catch for the key generation logic should only catch the specific exceptions that can be thrown. Since this is a new key generation path, catching Exception and wrapping it in CryptoException reduces visibility into actual failures. Consider catching only IncompatibleDeviceException and CryptoException that might propagate from RSAEncrypt.

The generic Exception catch block existed in the original code and was not modified by this PR. While catching specific exceptions would improve code quality, changing this would expand the scope beyond the security fix.

Copilot · 2025-12-19T09:03:37Z

auth0/src/test/java/com/auth0/android/authentication/storage/CryptoUtilTest.java

+        when(keyStore.getEntry(eq(KEY_ALIAS), nullable(KeyStore.ProtectionParameter.class)))
+            .thenReturn(mockKeyEntry);
+
+        byte[] aesKeyBytes = new byte[]{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};


The test uses a 16-byte AES key, but AES-256 requires a 32-byte key (AES_KEY_SIZE = 256 bits = 32 bytes). The implementation should validate the decrypted AES key length to ensure it matches the expected 32 bytes. Using a 16-byte key in the test doesn't properly validate that the migration logic would reject incorrectly-sized keys. Consider using a properly-sized 32-byte key in the test to match the actual AES-256 specification.

These tests use 16-byte AES keys, which is consistent with the mocking pattern in this test file. All tests in CryptoUtilTest.java use dummy key sizes (most use 3-byte keys, migration tests use 16-byte keys) because all encryption operations are fully mocked - no real cryptographic operations occur.

The tests validate BEHAVIOR (migration flow, storage updates, method calls) not actual encryption. Since RSADecrypt/RSAEncrypt are mocked, the key size doesn't affect test validity.

Changing to 32-byte keys would be cosmetic and inconsistent with existing test patterns. No fix needed.

Copilot · 2025-12-19T09:03:37Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+                            String newEncodedEncryptedAES = new String(
+                                Base64.encode(encryptedAESWithOAEP, Base64.DEFAULT), 
+                                StandardCharsets.UTF_8
+                            );


Missing validation of the decrypted AES key length after PKCS1 decryption from OLD_KEY_ALIAS. The original getAESKey implementation validated that the AES key has the expected length (32 bytes for 256-bit AES) before returning it. Without this validation, a corrupted or malformed legacy key could be migrated. Consider validating that decryptedAESKey.length equals AES_KEY_SIZE / 8 before proceeding with re-encryption.

While adding AES key length validation would be good defensive programming, it's beyond the scope of this PR, which focuses specifically on migrating from PKCS1 to OAEP padding for the security fix.

The existing error handling already addresses corrupted keys: if the decrypted AES key is malformed, subsequent encryption operations will fail and trigger the cleanup path that deletes corrupted keys and regenerates them. This behavior is consistent with the pre-migration code.

Copilot · 2025-12-19T09:03:38Z

auth0/src/test/java/com/auth0/android/authentication/storage/CryptoUtilTest.java

+    public void shouldDetectAndMigratePKCS1KeyToOAEP() throws Exception {
+        CryptoUtil cryptoUtil = newCryptoUtilSpy();
+
+        byte[] aesKeyBytes = new byte[]{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};


The test uses a 16-byte AES key (line 1701), but AES-256 requires a 32-byte key (AES_KEY_SIZE = 256 bits = 32 bytes). The implementation should validate the decrypted AES key length to ensure it matches the expected 32 bytes. Using a 16-byte key in the test doesn't properly validate that the migration logic would reject incorrectly-sized keys. Consider using a properly-sized 32-byte key in the test to match the actual AES-256 specification.

These tests use 16-byte AES keys, which is consistent with the mocking pattern in this test file. All tests in CryptoUtilTest.java use dummy key sizes (most use 3-byte keys, migration tests use 16-byte keys) because all encryption operations are fully mocked - no real cryptographic operations occur.

The tests validate BEHAVIOR (migration flow, storage updates, method calls) not actual encryption. Since RSADecrypt/RSAEncrypt are mocked, the key size doesn't affect test validity.

Changing to 32-byte keys would be cosmetic and inconsistent with existing test patterns. No fix needed.

Copilot · 2025-12-19T09:03:38Z

auth0/src/test/java/com/auth0/android/authentication/storage/CryptoUtilTest.java

+    public void shouldUseOAEPDirectlyForNewUsers() throws Exception {
+        CryptoUtil cryptoUtil = newCryptoUtilSpy();
+
+        byte[] aesKeyBytes = new byte[]{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};


The test uses a 16-byte AES key, but AES-256 requires a 32-byte key (AES_KEY_SIZE = 256 bits = 32 bytes). The implementation should validate the decrypted AES key length to ensure it matches the expected 32 bytes. Using a 16-byte key in the test doesn't properly validate that the migration logic would reject incorrectly-sized keys. Consider using a properly-sized 32-byte key in the test to match the actual AES-256 specification.

These tests use 16-byte AES keys, which is consistent with the mocking pattern in this test file. All tests in CryptoUtilTest.java use dummy key sizes (most use 3-byte keys, migration tests use 16-byte keys) because all encryption operations are fully mocked - no real cryptographic operations occur.

The tests validate BEHAVIOR (migration flow, storage updates, method calls) not actual encryption. Since RSADecrypt/RSAEncrypt are mocked, the key size doesn't affect test validity.

Changing to 32-byte keys would be cosmetic and inconsistent with existing test patterns. No fix needed.

pmathew92 · 2026-01-07T12:44:29Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+                    cause = cause.getCause();
+                }
+
+                if (fullMessage.contains("Incompatible padding mode") || 


String comparison for checking the old padding doesn't looks like a good method as it might return inconsistent behaviour. Would suggest to do some other approach to differentiate

pmathew92 · 2026-01-07T12:44:48Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

+            try {
+                return RSADecrypt(encryptedAESBytes);
+            } catch (IncompatibleDeviceException e) {
+                String fullMessage = e.toString();


This entire code block can be refactored to make it more readable

pmathew92 · 2026-01-07T12:46:02Z

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java

-            if (existingAES != null && existingAES.length == aesExpectedLengthInBytes) {
-                //Key exists and has the right size
-                return existingAES;
+        String encodedOldAES = storage.retrieveString(OLD_KEY_ALIAS);


Why do we need to handle both the OLD_KEY_ALIAS and KEY_ALIAS in separate block here ? Can't a single block like in the original work ?

utkrishtsahu requested a review from a team as a code owner May 19, 2025 05:13

semgrepcode-auth0 bot reviewed May 19, 2025

View reviewed changes

github-advanced-security bot found potential problems May 19, 2025

View reviewed changes

utkrishtsahu force-pushed the SDK-6001 branch from 4f67785 to fb25660 Compare July 7, 2025 04:53

github-advanced-security bot found potential problems Aug 11, 2025

View reviewed changes

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java Fixed Show fixed Hide fixed

pmathew92 requested a review from Copilot August 19, 2025 06:54

Copilot AI reviewed Aug 19, 2025

View reviewed changes

pmathew92 reviewed Aug 19, 2025

View reviewed changes

feat: Add PKCS1 to OAEP migration with 4096-bit RSA keys fixed the mi…

d9bce21

…gration logic for existing user

utkrishtsahu force-pushed the SDK-6001 branch from 212b04c to d9bce21 Compare December 17, 2025 05:57

github-advanced-security bot found potential problems Dec 17, 2025

View reviewed changes

utkrishtsahu added 2 commits December 17, 2025 12:12

UT cases update fix of 4096-bit RSA keys

e641aa1

added comment lines as per co pilot review

967376e

pmathew92 requested a review from Copilot December 19, 2025 08:53

handling co pilot review comments

715bcc8

Copilot started reviewing on behalf of pmathew92 December 19, 2025 08:54 View session

github-advanced-security bot found potential problems Dec 19, 2025

View reviewed changes

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java Dismissed Show dismissed Hide dismissed

auth0/src/main/java/com/auth0/android/authentication/storage/CryptoUtil.java Dismissed Show dismissed Hide dismissed

Copilot AI reviewed Dec 19, 2025

View reviewed changes

utkrishtsahu added 6 commits January 6, 2026 15:16

Fixing backward compatiblity and UT cases

6a44236

Merge remote-tracking branch 'origin/main' into SDK-6001

0cc81ea

handling CodeQL warning

db797c3

Add AES key length validation during PKCS1 to OAEP migration

399ddb0

Merge main into SDK-6001 to bring branch up to date

59357a1

Correction for failing Unit Test cases on CI

f992aea

pmathew92 reviewed Jan 7, 2026

View reviewed changes

	} catch (Exception e) {
	} catch (NoSuchAlgorithmException \| NoSuchPaddingException \| InvalidKeyException \| BadPaddingException \| IllegalBlockSizeException \| KeyStoreException \| UnrecoverableEntryException e) {

-        } catch (Exception e) {
+        } catch (InvalidKeyException
+                | NoSuchPaddingException
+                | IllegalBlockSizeException
+                | BadPaddingException
+                | KeyStoreException
+                | UnrecoverableEntryException
+                | CertificateException
+                | IOException
+                | ProviderException e) {

-                return RSADecrypt(encryptedAESBytes);
+                byte[] decryptedAESKey = RSADecrypt(encryptedAESBytes);
+                // Validate that the decrypted AES key has the expected length (e.g. 32 bytes for 256-bit AES)
+                if (decryptedAESKey == null || decryptedAESKey.length != AES_KEY_SIZE / 8) {
+                    // Treat this as corrupted key material: clean up and signal an error
+                    deleteRSAKeys();
+                    deleteAESKeys();
+                    throw new CryptoException("The RSA decrypted AES key has an unexpected length.");
+                }
+                return decryptedAESKey;

RSA encryption padding change from PKCS1Padding to OAEPWithSHA-256And… #834

Are you sure you want to change the base?

RSA encryption padding change from PKCS1Padding to OAEPWithSHA-256And… #834

Uh oh!

Conversation

utkrishtsahu commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

References

Testing

Checklist

Uh oh!

semgrepcode-auth0 bot May 19, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

semgrepcode-auth0 bot May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Copilot AI Aug 19, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Aug 19, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pmathew92 commented Aug 19, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

utkrishtsahu commented Dec 17, 2025

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 19, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

utkrishtsahu commented May 19, 2025 •

edited

Loading

semgrepcode-auth0 bot May 19, 2025 •

edited

Loading